Codecov Report

Attention: 22 lines in your changes are missing coverage. Please review.

Comparison is base (94eb10f) 78.93% compared to head (487c43f) 78.67%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff             @@
##             main     #111      +/-   ##
==========================================
- Coverage   78.93%   78.67%   -0.27%     
==========================================
  Files          65       66       +1     
  Lines        3713     3766      +53     
==========================================
+ Hits         2931     2963      +32     
- Misses        782      803      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Okay I have added commits to this to take advantage of the PR: ITensor/NamedGraphs.jl#39 in NamedGraphs. I have also made it so parallel vs sequential is specified by edges = Vector{Vector{NamedEdge{}}} where the internal vectors in the nest are done sequentially and the external ones in parallel. Currently the parallel updates involve a full copy of the message tensors DataGraph for each parallel instance. When we move to a better partition structure for them I will optimise this that to avoid over allocating memory - which can be excessive in the case of a large number of parallel groups (e.g. in a fully parallel update sequence).
For now I think it is okay and the default is all updates done sequentially anyway.
I have provided plenty of sequence examples in examples/belief_propagation/bpsequences.jl and you can see the power of our custom sequence finder there as it gives pretty significant speedups in every single case.

If they don't take too long to run, I think we should run examples/belief_propagation/bpsequences.jl from the tests. I feel uncomfortable accumulating all of these example files which are not being run in the tests, it's easy for things to become outdated.

There does seem to be an issue that this test suite takes a long time to run...

Yeah it doesn't too long so I will add it. Is there a reason for there being a separate test_sqrt_bp.jl file whilst it is also included in the test_examples.jl file? Which means the test gets run twice. If not, I will delete the test_sqrt_bp.jl file.

I also agree that we do have a lot of tests in the package and these can take a long time to run! We may have to think about streamlining tests a bit/ removing some which we consider less important from the runtests.jl list.

Yeah it doesn't too long so I will add it. Is there a reason for there being a separate test_sqrt_bp.jl file whilst it is also included in the test_examples.jl file? Which means the test gets run twice. If not, I will delete the test_sqrt_bp.jl file.

Hmm I guess test_sqrt_bp.jl is actually testing the output so seems better to keep that one and not include it in test_examples.jl.